Automatic drift detection and handling

ABSTRACT

In various example embodiments, a system, computer readable medium and method for schema update engine dynamically updating a target data storage system. Incoming data records are received. A front-end schema of the incoming data records is identified. The front-end schema and the current target schema are compared. Based on identifying a difference between the front-end schema and the current target schema, the current target schema is updated in order to be identical to the front-end schema. The current target data file is closed and the incoming data records are stored in a new target data file according to the updated target schema.

CROSS-REFERENCE TO RELATED APPLICATION

This patent application claims the benefit of U.S. Provisional PatentApplication No. 62/526,096, filed Jun. 28, 2017, entitled “AUTOMATICDRIFT DETECTION AND HANDLING”, which is incorporated by reference hereinin its entirety.

TECHNICAL FIELD

The subject matter disclosed herein generally relates to the technicalfield of special-purpose machines that provide for real-time updates ofdata record schemas of target data storage systems, includingsoftware-configured computerized variants of such special-purposemachines and improvements to such variants, and to the technologies bywhich such special-purpose machines become improved compared to otherspecial-purpose machines that facilitate provide for real-time updatesof data record schemas of target data storage systems.

BACKGROUND

According to conventional systems, front-end computer systems capturedata and format the data according to a pre-defined data schema. Apre-defined data schema provides for a label (or name) of each datafield and a data type for each respective data field. A pre-defined dataschema can be, for example, a data tree(s) structure such that a firstdata field can be a root of the pre-defined data schema and all otherdata fields are consider a child of (or dependent on) the first datafield.

BRIEF DESCRIPTION OF THE DRAWINGS

Various ones of the appended drawings merely illustrate exampleembodiments of the present disclosure and cannot be considered aslimiting its scope.

FIG. 1 is a network diagram depicting a computer system, within whichone example embodiment of a schema update engine may be deployed,according to an example embodiment;

FIG. 2 is a block diagram showing example components of a Schema UpdateEngine, according to some embodiments.

FIG. 3 is a flowchart illustrating an example method for updating atarget data schema of a target data storage system, according to anexample embodiment;

FIG. 4 shows a diagrammatic representation of machine in the exampleform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

The headings provided herein are merely for convenience and do notnecessarily affect the scope or meaning of the terms used.

DETAILED DESCRIPTION

The description that follows includes systems, methods, techniques,instruction sequences, and computing machine program products thatembody illustrative embodiments of the disclosure. In the followingdescription, for the purposes of explanation, numerous specific detailsare set forth in order to provide an understanding of variousembodiments of the inventive subject matter. It will be evident,however, to those skilled in the art, that embodiments of the inventivesubject matter may be practiced without these specific details. Ingeneral, well-known instruction instances, protocols, structures, andtechniques are not necessarily shown in detail.

A system, a machine-readable storage medium storing instructions, and acomputer-implemented method described herein are directed to a SchemaUpdate Engine. A front-end system(s) generates data records according toa front-end data schema. Such data records associate data field valueswith corresponding data types defined according to the front-end schema.Such data records are passed into a back-end data storage system(“target system”) for storage according to a back-end schema (“targetschema”) that should align with the front-end schema. However, thefront-end schema can be updated such that a new data field is added, adata field is deleted, a data field is renamed, or a type of a datafield is recast to a different type of data field. Once the front-endschema update(s) has occurred, the new data records generated inaccordance with the updated front-end schema are no longer in alignmentwith the target schema that is utilized for storing the new datarecords. The misalignment is caused by a drift—or real-timedifference—between definitions of data fields and their data types inthe updated front-end schema and the target schema. A schema updateengine identifies the drift and updates the target schema in real-timeas data records are passed from the front-end system for storage at thetarget system. As such, the new data records are stored in the targetsystem according to an updated target schema that aligns with theupdated front-end schema. It is understood that drift can be a result ofmutation of data characteristics, such as, an authorized user makingdirect changes to the front-end schema.

It is understood that various embodiments further include encodedinstructions that comprise operations to generate a user interface(s)and various user interface elements. The user interface and the varioususer interface elements can be displayed to be representative ofschemas, schema drifts, data field, data records, batches of datarecords, etc.

It is understood that various embodiments include the generation of oneor more modules that comprise source code that, when compiled by acomputing device(s), creates object code that causes the computingdevice(s) to perform one or more operations described herein. In otherembodiments, any of the modules comprise object code that causes thecomputing device(s) to perform various operations described herein. Insome embodiments, each module(s) can be permanently configuredcircuitry, such as ASICs, etc. In various embodiments, all operations ofthe schema update engine can be performed by a computer system, orcomputer module(s), or software modules situated between a plurality ofdata storage systems, such that the schema update engine accesses datarecords being transmitted between the plurality of data storage systems

Other embodiments include the generation of one or more modules thatcomprise source code that, when compiled by a server computingdevice(s), creates object code that causes the server computingdevice(s) to perform one or more operations described herein incommunication with one or more client computing devices. In otherembodiments, any of the modules comprise object code that causes theserver computing device(s) to perform various operations describedherein in communication with the one or more client computing devices.

Turning now to FIG. 1, FIG. 1 is a network diagram depicting a computersystem 100, within which one example embodiment of a schema updateengine may be deployed, according to some embodiments of the invention.

A networked system 102, in the example, provides server-sidefunctionality, via a network 104 (e.g., the Internet or Wide AreaNetwork (WAN)) to one or more data storage systems. FIG. 1 illustrates,for example, application(s) 110 executed at a front-end data storagesystem 106 (for example a Hadoop file system or a MapR file system) tocapture data and format the captured data into one or more data recordsformatted according to a current version of a front-end data schemastored in a front-end metastore 115. In particular, the data records maybe formatted according to a traditional RDBMS format, the data beingorganized into one or more tables of columns and rows. The metadataincludes a schema for each of the tables. The tables may be organizedinto partitions. Partitions divide a table into related parts based onthe values of partitioned columns such as date, city, and department.Partitions make it is easy to query a portion of the data. When thetables are organized into partitions, the metadata may also includepartition metadata. A back-end data storage system 107 (“target system”)(for example a Hadoop file system or a MapR file system) stores datarecords in a current target data file according to a current targetschema. The target system 107 includes a target metastore 116 storingmetadata including the current target schema. The target system 107further includes an application(s) 111 to store received data records.The schema update engine 124 adds information to a header of eachincoming data record received form the front-end system 106 beforepassing the data record to the target system 107. The target system 107performs record-based writes to the target system 107 based on a targetdirectory, and optionally a data serialization framework, and/or acolumnar storage file format. For example, the schema update engine 124assembles the path where each incoming data record should be stored, andwrites the generated path in a target directory attribute in the recordheader of each incoming data record. The schema update engine 124 mayadditionally write a data serialization framework (like Avro) and/orcolumnar storage file format (like Apache Parquet) to correspondingattributes in the record header of the incoming data record.

An Application Program Interface (API) server 120 and a web server 118are coupled to, and provide programmatic and web interfaces respectivelyto, an application server(s) 122. The application server 122 hosts aschema update engine 124. The application server 122 is, in turn, shownto be coupled to a database server(s) 128 that facilitates access to aschema database(s) 130, which stores previously inferred de factoschemas of the front-end data storage system 106. In other embodiments,the schema update engine application 124 can be coupled to a schemacache, which stores previously inferred de facto schemas of thefront-end data storage system 106.

While the schema update engine 124 is shown in FIG. 1 to form part ofthe networked system 102, it will be appreciated that, in alternativeembodiments, the schema update engine 124 may form part of a servicethat is separate and distinct from the networked system 102.

Further, the computer system 100 is of course not limited to such anarchitecture as shown in FIG. 1, and could equally well find applicationin a distributed, or peer-to-peer, architecture system, for example. Anyportion, or portions, of the schema update engine 124 may reside and beexecuted from any kind of computing device. The schema update engine 124could also be implemented as standalone software program(s), which doesnot necessarily have networking capabilities.

FIG. 2 is a block diagram showing example components of a schema updateengine, according to some embodiments.

The input module 205 controls, manages and stores information related toany inputs from one or more components of system 102 as illustrated inFIG. 1. In various embodiments, the inputs include one or more datarecords transmitted between data storage systems. For example, the inputcan be a batch of data records being sent from a front-end data storagesystem to a target data storage system, such as a back-end data storagesystem.

The output module 210 controls, manages and stores information relatedto which sends any outputs to one or more components of a target datastorage system. In some embodiments, the output is an operation(s), oran operation call(s), that modifies at least a portion of a data schemaof target data storage system.

The batch module 215 manages, controls, stores, and accesses informationrelated to collecting one or more data records transmitted from a datastorage system. For example, the batch module 315 collects a batch ofincoming data records being sent from a front-end data storage system toa target data storage system.

The de facto schema module 220 manages, controls, stores, and accessesinformation related to inferring a de facto schema of a data storagesystem. For example, de facto schema module 320 determines whether adrift has occurred in the data schema of the data storage system that isthe source of incoming data records.

The schema update module 225 manages, controls, stores, and accessesinformation related to updating a target data schema of a target datastorage system. Based on detecting a drift of in the data schema of thedata storage system that is the source of incoming data records, theschema update module 225 accesses a target data schema of a target datastorage system in order to update the target data schema.

FIG. 3 is a flowchart 300 illustrating an example method for updating atarget data schema of a target data storage system, according to anexample embodiment.

The schema update engine 124 performs a metadata analysis of a batch ofdata records being sent to the target system 107. At operation 310, theschema update engine 124 reads data fields of the data records in thebatch and generates a de facto schema. The de facto schema representsthe current state of the front-end data schema—as detected by the schemaupdate engine 124. For example, the schema update engine 124 extractsthe data fields of the incoming data records of a batch; and generatesthe de facto schema based on the extracted data fields by combining theextracted data fields and removing duplicate extracted data fields. Thiscan be done via a union operation of the extracted data fields. Forexample, the schema update engine 124 iterates through each data recordin the batch and adds data fields—that are extracted from the respectivedata records—to the de facto schema via a union operation of the readdata fields. A union operation can be performed using a UNION operator.The UNION operator combines all the data fields of the data records inthe batch, and removes duplicate rows to generate the de facto schema.The schema update engine 124 accesses the target system 107 to obtain atarget schema definition, which represents a current state of the targetdata schema (“target schema”).

At operation 320, the schema update engine 124 compares the de factoschema to the current state of the target schema. Upon detecting adifference in the de facto schema (such as a new data field, a deleteddata field, a recast data type of data field, a renamed data field), theschema update engine 124 identifies one or more operations (e.g., read,write, delete) to be performed on the target schema definition to updatethe target schema such that it is in alignment (i.e. the same as) the defacto schema. For example, when the difference between the front-endschema and the current target schema is an added data field, theoperation to be performed is adding the added data field to the currenttarget schema. When the difference between the front-end schema and thecurrent target schema is a deleted data field, no operation is to beperformed on the current target schema, the deleted data field shouldsimply be ignored when storing the incoming data records. When thedifference between the front-end schema and the current target schema isa recast data type of a data field, the operation to be performed isrecasting the type of the data field of the current target schema. Whenthe difference between the front-end schema and the current targetschema is a renamed data field, the operation to be performed isrenaming the data field of the current target schema. In the case of adatabase table structure, when the difference between the front-endschema and the current target schema is a new table, the schema updateengine 124 creates the table structure inferred from the read incomingdata fields. When the difference between the front-end schema and thecurrent target schema is a partition of a table, the operation to beperformed is creating a partition of the table in the target schema.When the difference between the front-end schema and the current targetschema is one or more columns and/or rows, the operation to be performedis adding one or more columns and/or rows at which the new datafields/types will be listed.

In an exemplary embodiment, the schema update engine 124 detects driftby reading data fields (such as a database table structure) of one ormore incoming data records. The read data fields are compared to acached target schema. If a first comparison returns a difference betweenthe read data fields and the cached target schema, the current targetschema is accessed at the target system and the read data fields arecompared again to the current target schema. If a second comparisonreturns a difference between the read data fields and the current targetschema, the schema update engine 124 has detected a drift between thefront-end schema and the target schema. The schema update engine 124writes, to a target schema definition file of the target system, thedatabase table structure of the read incoming data records in order toupdate the target schema. The schema update engine 124 replaces thepreviously cached target schema by placing the updated target schema inthe cache.

However, if the first comparison returns no difference between the readdata fields and the cached target schema, the schema update engine 124still runs the second comparison between the read data fields and thecurrent target schema. If the second comparison returns a resultrepresenting that the same table structure inferred from the read datafields is present in the target schema, then there is no drift detected.However, if the inferred table structure is not present in the targetschema, then a drift has been detected.

At operation 330, the schema update engine 124 instructs the targetsystem 107 to update the target schema. In some embodiments, the schemaupdate engine 124 writes, to a target schema definition file of thetarget system, the operations to be performed on the current targetschema in order to update the current target schema. In particular, theschema update engine 124 may generate a metadata record that describesthe operations to be performed and send it to the metastore 116 of thetarget system. The metastore 116 updates the target schema by performingthe operations described in the metadata record on the current targetschema. In other embodiments, the schema update engine 124 writes, to atarget schema definition file of the target system, the updated targetschema to be used instead of the current target schema. In particular,the schema update engine 124 may generate a metadata record thatdescribe the updated target schema and send it to the target metastore116. The target megastore 116 updates the target schema by replacing thecurrent target schema with the updated target schema. When the targetmetastore 116 receives the metadata record, it may first compare theupdated target schema with the current target schema and based on thiscomparison only performs the operations that need to be performed on thetarget schema to update it according to the updated target schema.

At operation 340, the schema update engine 124 instructs the targetsystem 107 to roll target files, namely close the current target file,open a new target file generated according to the updated target schemaand store the incoming data records in the new target data file.Operation 340 may be performed simultaneously with operation 330 schemaupdate engine For example, the schema update engine 124 may addinformation to the header of each incoming data record before passingthe records to the target system 107. In particular, the schema updateengine 124 may add a roll indicator in a corresponding attribute in therecord header of the incoming data record. Upon receiving the incomingdata record and reading the roll indicator in the record header, thetarget system 107 closes the current target file, generates a new targetdata file based on the updated schema and writes the incoming datarecord in the new target data file according to the updated targetschema.

Computer System(s)

FIG. 4 shows a diagrammatic representation of machine in the exampleform of a computer system 400 within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In alternative embodiments, themachine operates as a standalone device or may be connected (e.g.,networked) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client machine in server-clientnetwork environment, or as a peer machine in a peer-to-peer (ordistributed) network environment. The machine may be a server computer,a client computer, a personal computer (PC), a tablet PC, a set-top box(STB), a Personal Digital Assistant (PDA), a cellular telephone, a webappliance, a network router, switch or bridge, or any machine capable ofexecuting a set of instructions (sequential or otherwise) that specifyactions to be taken by that machine. Further, while only a singlemachine is illustrated, the term “machine” shall also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methodologies discussed herein.

The example computer system 400 includes a processor 402 (e.g., acentral processing unit (CPU) a graphics processing unit (GPU) or both),a main memory 404 and a static memory 406 (with one or more sets ofinstructions 407) which communicate with each other via a bus 408. Thecomputer system 400 may further include a video display unit 410 (e.g.,a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system 400 also includes an alphanumeric input device 412(e.g., a keyboard), a cursor control device 414 (e.g., a mouse), a diskdrive unit 416, a signal generation device 418 (e.g., a speaker) and anetwork interface device 420.

The disk drive unit 416 includes a machine-readable medium 422 on whichis stored one or more sets of instructions 424 (e.g., software)embodying any one or more of the methodologies or functions describedherein. The software 424 may also reside, completely or at leastpartially, within the main memory 404 and/or within the processor 402during execution thereof by the computer system 400, the main memory 404and the processor 402 also constituting machine-readable media.

The software 424 may further be transmitted or received over a network104 via the network interface device 420.

While not illustrated, it is understood that that computer system 400can further include sensors that create data regarding a thermal stateof the computer system 400, an orientation of the computer system 400and a current location of the computer system 400. In variousembodiments, the computer system 400 includes a temperature sensor, anaccelerometer and/or a global position system for identifying thecurrent location of the computer system 400.

While the machine-readable medium 422 is shown in an example embodimentto be a single medium, the term “machine-readable medium” should betaken to include a single medium or multiple media (e.g., a centralizedor distributed database, and/or associated caches and servers) thatstore the one or more sets of instructions. The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring, encoding or carrying a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethodologies of the subject matter described herein. The term“machine-readable medium” shall accordingly be taken to include, but notbe limited to, solid-state memories, optical and magnetic media, andcarrier wave signals.

Thus, a method(s) and system(s) to detect a thermal state(s) andposition(s) of a computing device are disclosed herein in accordancewith various embodiments. Although the subject matter herein has beendescribed with reference to specific example embodiments, it will beevident that various modifications and changes may be made to theseembodiments without departing from the broader spirit and scope of theinvention. Accordingly, the specification and drawings are to beregarded in an illustrative rather than a restrictive sense.

It is submitted with the understanding that it will not be used tointerpret or limit the scope or meaning of the claims. In addition, inthe foregoing Detailed Description, it can be seen that various featuresare grouped together in a single embodiment for the purpose ofstreamlining the disclosure. This method of disclosure is not to beinterpreted as reflecting an intention that the claimed embodimentsrequire more features than are expressly recited in each claim. Rather,as the following claims reflect, inventive subject matter lies in lessthan all features of a single disclosed embodiment. Thus the followingclaims are hereby incorporated into the Detailed Description, with eachclaim standing on its own as a separate embodiment.

The invention claimed is:
 1. A computer implemented method todynamically update a target data storage system, the method comprising:receiving incoming data records; identifying a front-end schema of theincoming data records; comparing the front-end schema to a currenttarget schema according to which the target data storage system storesreceived data records in a current target data file; and based onidentifying a difference between the front-end schema and the currenttarget schema: generating a metadata record describing data operationsto be performed on the current target schema to reconcile the identifieddifference between the front-end schema and the current target schema;transmitting the metadata record to a target metastore, the targetmetastore configured to perform the data operations described by themetadata record on the current target schema; receiving, from the targetmetastore, an updated target schema that is identical to the front-endschema; updating the current target schema using the updated targetschema received from the target metastore; adding a plurality of rollindicators in a plurality of record headers of the incoming datarecords; reading the plurality of record headers comprising theplurality of roll indicators; in response to reading the plurality ofrecord headers comprising the plurality of roll indicators, closing thecurrent target data file; and storing the incoming data records in a newtarget data file according to the updated target schema.
 2. The methodof claim 1, wherein the identifying of the front-end schema of theincoming data records comprises: collecting the incoming data recordsinto batches; extracting data fields of the incoming data records of abatch; and generating a de facto schema based on the extracted datafields, the de facto schema being considered as the front-end schema. 3.The method of claim 2, wherein generating the de facto schema based onthe extracted data fields comprises combining the extracted data fieldsand removing duplicate extracted data fields.
 4. The method of claim 1,wherein comparing the front-end schema to the current target schemacomprises: comparing the front-end schema to a cached target schema; andbased on identifying a difference between the front-end schema and thecached target schema, accessing the current target schema, comparing thefront-end schema to the current target schema, and updating the cachedtarget schema with the current target schema.
 5. The method of claim 4,wherein comparing the front-end schema to the current target schemafurther comprises: based on identifying no difference between thefront-end schema and the cached target schema, accessing the currenttarget schema, comparing the front-end schema to the current targetschema, and updating the cached target schema with the current targetschema.
 6. The method of claim 1, wherein the difference between thefront-end schema and the current target schema is any one or more of anadded data field, a deleted data field, a recast data type of datafield, or a renamed data field.
 7. The method of claim 1, whereinupdating the current target schema comprises creating a partition in thecurrent target schema, adding one or more data field to the currenttarget schema, renaming one or more data field of the current targetschema, or recasting a type of a data field of the current target schemato a different type of data field.
 8. A computer system to dynamicallyupdate a target data storage system, the computer system comprising: amemory to store computer executable instructions; and at least onecomputer processor coupled to the memory to execute the instruction,that upon execution perform operations comprising: receiving incomingdata records; identifying a front-end schema of the incoming datarecords; comparing the front-end schema to a current target schemaaccording to which the target data storage system stores received datarecords in a current target data file; and based on identifying adifference between the front-end schema and the current target schema:generating a metadata record describing data operations to be performedon the current target schema to reconcile the identified differencebetween the front-end schema and the current target schema; transmittingthe metadata record to a target metastore, the target metastoreconfigured to perform the data operations described by the metadatarecord on the current target schema; receiving, from the targetmetastore, an updated target schema that is identical to the front-endschema; updating the current target schema using the updated targetschema received from the target metastore; adding a plurality of rollindicators in a plurality of record headers of the incoming datarecords; reading the plurality of record headers comprising theplurality of roll indicators; in response to reading the plurality ofrecord headers comprising the plurality of roll indicators, closing thecurrent target data file; and storing the incoming data records in a newtarget data file according to the updated target schema.
 9. The systemof claim 8, wherein identifying the front-end schema of the incomingdata records comprises: collecting the incoming data records intobatches; extracting data fields of the incoming data records of a batch;and generating a de facto schema based on the extracted data fields, thede facto schema being considered as the front-end schema.
 10. The systemof claim 9, wherein generating the de facto schema based on theextracted data fields comprises combining the extracted data fields andremoving duplicate extracted data fields.
 11. The system of claim 8,wherein comparing the front-end schema to the current target schemacomprises: comparing the front-end schema to a cached target schema;based on identifying a difference between the front-end schema and thecached target schema, accessing the current target schema, comparing thefront-end schema to the current target schema, and updating the cachedtarget schema with the current target schema.
 12. The system of claim11, wherein comparing the front-end schema to the current target schemafurther comprises: based on identifying no difference between thefront-end schema and the cached target schema, accessing the currenttarget schema, comparing the front-end schema to the current targetschema, and updating the cached target schema with the current targetschema.
 13. The system of claim 8, wherein the difference between thefront-end schema and the current target schema is an added data field, adeleted data field, a recast data type of data field, or a renamed datafield.
 14. The system of claim 8, wherein updating the current targetschema comprises creating a partition in the current target schema,adding one or more data field to the current target schema, renaming oneor more data field of the current target schema, or recasting a type ofa data field of the current target schema to a different type of datafield.
 15. A non-transitory computer readable medium storinginstructions thereon, which when executed by a processor cause acomputer system to perform operations comprising: receiving incomingdata records; identifying a front-end schema of the incoming datarecords; comparing the front-end schema to a current target schemaaccording to which the target data storage system stores received datarecords in a current target data file; and based on identifying adifference between the front-end schema and the current target schema:generating a metadata record describing data operations to be performedon the current target schema to reconcile the identified differencebetween the front-end schema and the current target schema; transmittingthe metadata record to a target metastore, the target metastoreconfigured to perform the data operations described by the metadatarecord on the current target schema; receiving, from the targetmetastore, an updated target schema that is identical to the front-endschema; updating the current target schema using the updated targetschema received from the target metastore; adding a plurality of rollindicators in a plurality of record headers of the incoming datarecords; reading the plurality of record headers comprising theplurality of roll indicators; in response to reading the plurality ofrecord headers comprising the plurality of roll indicators, closing thecurrent target data file; and storing the incoming data records in a newtarget data file according to the updated target schema.
 16. Thecomputer readable medium of claim 15, wherein identifying a front-endschema of the incoming data records comprises: collecting the incomingdata records into batches; extracting data fields of the incoming datarecords of a batch; and generating a de facto schema based on theextracted data fields, the de facto schema being considered as thefront-end schema.
 17. The computer readable medium of claim 16, whereingenerating the de facto schema based on the extracted data fieldscomprises combining all the extracted data fields and removing duplicateextracted data fields.
 18. The computer readable medium of claim 15,wherein comparing the front-end schema to the current target schemacomprises: comparing the front-end schema to a cached target schema;based on identifying a difference between the front-end schema and thecached target schema, accessing the current target schema, comparing thefront-end schema to the current target schema, and updating the cachedtarget schema with the current target schema.
 19. The computer readablemedium of claim 18, wherein comparing the front-end schema to thecurrent target schema further comprises: based on identifying nodifference between the front-end schema and the cached target schema,accessing the current target schema, comparing the front-end schema tothe current target schema, and updating the cached target schema withthe current target schema.
 20. The computer readable medium of claim 15,wherein the difference between the front-end schema and the currenttarget schema is an added data field, a deleted data field, a recastdata type of data field, or a renamed data field.
 21. The computerreadable medium of claim 15, wherein updating the current target schemacomprises creating a partition in the current target schema, adding oneor more data field to the current target schema, renaming one or moredata field of the current target schema, or recasting a type of a datafield of the current target schema to a different type of data field.